OSCAR Protocol Document Version 1.0.00 July 2003 (Updated March 2005) Nemisis 1.0 Introduction The purpose of this document is not to replace the existing OSCAR documents so to speak, but to be a precursor to them, and fill in the gaps that they leave. The problem I first noticed when I began my work with the OSCAR protocol, is that all the documents use terminology, that many are unfamiliar with. The documents are more of a reference then an actual guide to understanding the protocol. They were all written while in the mind set that someone who was already familiar with the protocol, or at least protocols in general would be using them. It is my hope, that this document will correct those assumptions, and bring Oscar to a more user friendly level, by giving a less familiar user the ability to utilize it. The example packets in this document have been recreated. Some of the information has been changed to protect privacy, and some to make things easier. I hope that after reading this document, and viewing the examples that you will be ready to start working with OSCAR. I also hope that after reading this, you will be able to make good use of documents such as king-ant.net and FAIM. Let me just say that this document is of course, incomplete. It is a compilation of my knowledge of OSCAR. As my knowledge grows, so will this document. Some of you that are reading this, will find that the first part of this document, which is a background on the terminology, and the makeup of the protocol in general to be dull, and you may wish to skip ahead. 1.1 What is a protocol In our case, a protocol is a means with which data is transfered from Point A to Point B. The protocol is a set of rules that are applied to construct the data before it is sent, so that upon arrival it can be decoded, and used. The most common protocol is TCP and IP. Normally written as TCP/IP it should not be confused as one protocol, it is two independent ones. 1.2 How is the data sent Data sent using the Oscar protocol is sent using TCP (transmission control protocol). The TCP packet has the Oscar packet embedded within it. If your using Spynet Packet Sniffer, the TCP part of the packet appears in the first three lines of the packet, and the OSCAR packet (Starting with an asterix) Starts mid way through the third line. 0000: 00 E0 98 76 5C A7 00 08 20 D8 0B FC 08 00 45 00 ...v\... .....E. 0010: 00 9E B3 D7 40 00 28 06 1E AC 40 0C 1D 7B 41 60 ....@.(...@..{A` 0020: E0 EF 14 46 08 FD 8C 0B 50 C6 5C A4 9A A5 50 18 ...F....P.\...P. 0030: 40 00 8A 99 00 00 2A 02 C1 89 00 5A 00 13 00 03 @.....*....Z.... 0040: 00 00 00 00 00 02 00 04 00 2E 01 90 00 3D 00 C8 .............=.. 0050: 00 C8 00 01 00 01 00 96 00 0C 00 0C 00 00 00 32 ...............2 0060: 00 32 00 00 00 00 00 00 00 00 00 00 00 01 00 00 .2.............. 0070: 00 00 00 0A 00 01 00 0C 00 02 00 02 00 FE 00 03 ................ 0080: 00 02 01 FC 00 05 00 02 00 64 00 06 00 02 00 61 .........d.....a Notice the * that is the first part of the FLAP header. We will look into this in further detail later. 1.3 What is the data sent as The data is sent as ASCII (American Standard code for information interchange, Pronounced ASK-Key). At a glance, it will look like a bunch of gibberish. The graphical representation of the packet is misleading. In the Oscar protocol, Characters (like A B C D 1 2 and 3) can mean a variety of things, as you will see. ASCII also has graphical character representations for things such as the ESC key, and the ENTER button (known as a carriage return). Almost every key on your keyboard has an ASCII character representation. The representation however, will normally be a rectangular box, since there is no real graphical representation for the key. 1.4 How can I view a packet If you are reading this document, and you downloaded it from my web site or found that it came with AIM Pimped, You should also have received a 'Packet Sniffer' the name of the packet sniffer is SpyNet. You can install it and use it for 30 days, after that you will have to register it, or find a crack for it (I do not suggest this, because it is illegal but there is a security site you might check out www.cracks.am). After installing Spynet you should run 'Capture Net' it should have installed to your start menu. Capture Net is the packet sniffer. Set the Hardware filter to Promiscuous, and hit the Modify button. Select only TCP/IP. Then go to the port section, and enter 5190, and hit insert. This means that you are filtering out all packets that are not TCP and all ports that are not 5190 (the normal AIM connection port). Hit start, and send an Instant Message. You should see the packet appear. Click on the packet, and it will show you the contents. 1.5 What the hell am I seeing Your seeing two graphical representations of the packet. The first is hexadecimal, the second (to the right) is ASCII. ASCII is how the actual packet is sent, but you will notice a lot of periods, "....." and such. 99% of the time, when you see a period, its Capture Net, giving a graphical representation, to a Character that has none. (The enter Key, space bar, delete key etc.) 2.0 Numbering Systems Numbering systems are complex. There are many of them. We are concerned in this document with only two. Hexadecimal and Decimal. 2.1 Decimal The decimal system is a Base10 number system. It means that with 10 characters, you can make any number possible. The characters, as I'm sure you know, are 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9. 2.2 Hexadecimal Hexadecimal is a Base16 number system. This means that it uses 16 characters to represent all numbers. The Characters, as you may or may not know, are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and F. When you see a hexadecimal representation of data, you will notice that its not AA AB 0 A1 F E. Its AA AB 00 A1 0F 0E. The value is the same, but the additional 0 is needed. 3.0 Decoding a packet If you got this from my site or with AIM Pimped, You should also have the 'Nemisis OSCAR Packet Tools' program. This is a program I made to make decoding an Oscar packet easy. If you learn this program, and its functions, then decoding packets should be a breeze. 3.1 Strip Packets Strip packets is a button in Oscar Packet tools. It will take a full packet, straight from Capture Net such as this.... 0000: 00 E0 98 76 5C A7 00 08 20 D8 0B FC 08 00 45 00 ...v\... .....E. 0010: 00 9E B3 D7 40 00 28 06 1E AC 40 0C 1D 7B 41 60 ....@.(...@..{A` 0020: E0 EF 14 46 08 FD 8C 0B 50 C6 5C A4 9A A5 50 18 ...F....P.\...P. 0030: 40 00 8A 99 00 00 2A 02 C1 89 00 5A 00 13 00 03 @.....*....Z.... 0040: 00 00 00 00 00 02 00 04 00 2E 01 90 00 3D 00 C8 .............=.. 0050: 00 C8 00 01 00 01 00 96 00 0C 00 0C 00 00 00 32 ...............2 0060: 00 32 00 00 00 00 00 00 00 00 00 00 00 01 00 00 .2.............. 0070: 00 00 00 0A 00 01 00 0C 00 02 00 02 00 FE 00 03 ................ 0080: 00 02 01 FC 00 05 00 02 00 64 00 06 00 02 00 61 .........d.....a And get rid of the ASCII etc, so that its just the hex, and then convert the hex to decimal, to give you something like this.... 64 0 241 23 0 0 42 2 193 141 0 195 0 3 0 11 0 0 137 29 31 186 13 67 114 111 115 115 102 105 114 101 67 117 114 116 0 0 0 5 0 1 0 2 0 16 0 13 0 128 9 70 19 72 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 75 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 9 70 19 65 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 67 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 69 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 71 76 127 17 209 130 34 68 69 83 84 0 0 0 15 0 4 0 0 104 176 0 29 0 9 0 0 0 5 2 1 210 4 114 0 3 0 4 62 116 167 60 42 2 193 142 0 195 0 3 0 11 0 0 137 29 31 187 13 103 111 100 101 115 115 111 108 111 118 101 49 56 0 0 0 5 0 1 0 2 0 16 0 13 0 128 9 70 19 72 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 75 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 9 70 19 65 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 67 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 69 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 71 76 127 17 209 130 34 68 69 83 84 0 0 0 15 0 4 0 2 113 54 0 29 0 9 0 0 0 5 2 1 210 4 114 0 3 0 4 62 114 158 182 42 2 193 143 0 217 0 3 0 11 0 0 137 29 31 188 6 68 65 74 51 49 48 0 0 0 5 0 1 0 2 0 48 0 13 0 128 9 70 19 72 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 75 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 9 70 19 65 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 67 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 69 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 71 76 127 17 209 130 34 68 69 83 84 0 0 0 15 0 4 0 0 78 244 0 29 0 38 0 0 0 5 2 1 210 4 114 0 1 1 16 82 72 72 219 160 224 214 34 243 46 177 207 39 103 211 221 0 129 0 5 2 2 87 13 210 0 3 0 4 62 116 192 248 42 2 193 144 0 118 0 3 0 11 0 0 137 29 31 189 9 71 114 107 71 105 114 108 49 55 0 0 0 5 0 1 0 2 0 36 0 13 0 32 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 0 14 0 32 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 0 15 0 4 0 0 210 204 0 3 0 4 62 116 61 32 42 2 193 145 1 44 0 1 0 5 128 0 0 1 0 4 0 6 0 1 0 2 0 3 0 13 0 2 0 24 0 5 0 12 54 52 46 49 50 46 50 54 46 50 52 51 0 6 1 0 249 53 10 114 118 135 175 171 128 104 170 116 94 235 167 114 253 72 113 99 225 46 116 78 192 229 114 82 5 76 29 70 214 175 216 147 255 175 172 188 69 215 98 126 8 120 153 118 0 165 255 0 243 34 144 233 239 62 237 109 23 180 224 3 23 85 125 82 25 10 240 89 36 55 91 58 6 42 136 226 255 15 250 205 198 169 132 219 191 204 143 128 176 113 82 173 248 1 118 111 54 225 105 112 101 252 17 17 47 127 119 183 26 23 77 101 22 82 156 148 25 71 251 99 43 201 126 237 207 154 28 66 160 232 176 27 162 98 203 216 181 191 153 107 77 138 118 166 24 87 141 213 70 177 164 67 12 149 3 207 135 11 141 107 232 110 135 109 23 229 82 255 218 118 3 29 25 157 129 189 54 221 177 89 135 250 150 166 77 9 53 248 122 102 158 214 131 211 218 168 72 73 219 80 234 235 194 248 252 164 208 248 154 175 91 144 124 199 11 122 29 148 245 24 168 247 98 234 8 157 93 109 34 77 240 200 20 226 130 6 165 52 23 190 86 27 48 133 115 81 179 95 8 218 98 156 42 2 193 146 0 204 0 3 0 11 0 0 137 29 31 190 16 83 84 105 76 76 32 105 78 32 84 72 79 85 71 72 84 0 0 0 6 0 1 0 2 0 48 0 4 0 2 0 16 0 13 0 128 9 70 19 72 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 75 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 0 9 70 19 65 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 67 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 69 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 70 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 71 76 127 17 209 130 34 68 69 83 84 0 0 0 15 0 4 0 0 61 90 0 29 0 9 0 0 0 5 2 1 210 4 114 0 3 0 4 62 116 210 146 42 2 193 147 0 219 0 3 0 11 0 0 137 29 31 192 11 116 104 101 49 100 106 115 109 111 107 105 0 0 0 6 0 1 0 2 0 17 0 4 0 2 0 27 0 13 0 128 9 70 19 72 76 127 17 209 130 34 68 69 83 84 0 0 9 70 19 75 76 127 17 209 130 34 68 69 83 84 0 0 116 143 36 32 98 135 17 209 130 34 68 69 83 84 0 You may be asking yourself why were are converting the packet to decimal. This is the easiest way to view the packet for what it is. Sometimes in OSCAR, a characters numerical representation (The number is has on an ASCII chart) will mean nothing, and sometimes it will mean the length of something. So it is imperative, at least in the beginning, to change the packets to decimal so we can see where these are. 3.2 Get Word Get Word will take two decimal numbers, and give you there actual value. This is crucial because you can only represent up to 255 with the ASCII chart, so you need to use two characters to represent one number. So if you enter 0 1 you would get back 1. If you entered something like 22 10 you would get back a number much higher. This usefulness of this will become apparent later in this document. A character, as I relate to it in this document is the same as a byte. 1 is a character, and it takes up a byte. 3.3 Get dWord Get dWord is almost the same as Get Word accept it takes 4 numbers an gives you there actual value. (ex. 0 0 0 1 would = 1) 3.4 TwoByteLen This is the opposite of Get Word. It takes one number, and gives it a Two Byte Word value. So 255 would return 0 255. 3.5 Length This gives you the length of a string of characters, it is useful in obtaining the length of a packet. (mostly only used for decoding a packet) 3.6 General Definitions 3.6.1 Byte A byte can hold one character. Like A or like 9. That is how they appear if your viewing the packet in ASCII. If your viewing them in decimal, then your viewing there numerical representation as relates to the ASCII chart. If your viewing them in Hex, it would seem like there was two bytes, because you see 00, but thats just a graphical representation of one byte, and it really just means 0, or Chr(0), or The graphical representation as is shown on an ASCII chart. 3.6.2 Capabilities (Caps) Later in this document we talk about Caps, suffice to say that for now, you can think of a capability as a feature. IMs are a cap, and File Transfer is a Cap. 3.6.2 CHR CHR is a visual basic command that takes a number, say 12 and references the ASCII chart to give it a visual representation. Usage: Chr(12) 3.6.3 FAIM FAIM was as far as I know, the first OSCAR document. Its very complex to understand. The hardest thing to understand is what they mean when they say FAMILY 0x0003 or 0x0004 or something similar. Let me explain. I'm not positive but I'm pretty sure the 0x is another way of saying Hex. Next we look at 0004 thats 00 04. Or in Decimal its, 0 4. That means that 0x0004 is Family 0 4 (or just 4). 4.0 FLAP Flap is the first part of the Oscar packet. It is made up of 6 bytes. The first byte is always Chr(42) (an asterix (*)) Whenever your looking for the start of an Oscar packet, you should look for the *. If you have the packet in decimal form, look for a 42. Be warned though, that Character 42 can appear when it is not the start of a packet, so be sure to look at the rest of the FLAP header that follows it, and then look for the SNAC data, to make sure its an actual packet start. All data before the first FLAP header can be discarded. Normally the data before the FLAP header, is just TCP data, and is not needed. WARNING: Flap Headers can be misleading, the length is not always what it says it is. 4.1 The FLAP Header. The FLAP header, as was said before, is 6 bytes the first being an asterix. The second being the channel. The channel tells you what type of data you should expect next. A normal FLAP Header looks like this in HEX; 2A 02 C1 89 00 5A 4.1.0 The Flap Start Command This is ALWAYS an Asterix. In hex it looks like this 2A 4.2.1 Channel 1 This Channel is used for New Connection management. When you connect to the login server, data is sent on this channel. In Hex it looks like this; 01 4.2.2 Channel 2 This is the main channel. Everything else aside from connection management, and FLAP level errors are sent on this channel. (IMS, Chat, etc). In Hex it looks like this; 02 4.2.3 Channel 3 This channel is used for flap level errors. In Hex it looks like this; 03 4.2.3 Channel 4 This channel is used when your going to disconnect. You will rarely, if ever need to use this channel. In Hex it looks like this; 04 4.3 Sequence Number (Word Value) This part of the header keeps track of the number of packets that have been sent. If you send a packet with an incorrect flap header; the server will disconnect you instantly. The Sequence number is a word value (remember, this means two bytes). If your sending the first packet it would of course be 1, or as a word 0 1 (00 01 in hex). Keep track of these in a variable or some such, and add the flap header as close to real time as possible. Meaning right before you send the packet. In hex it can look like this C1 89 4.4 Flap Data Field Length (Word Value) This is the last part of the packet. Its a word value for the length of the data contained in the flap data field. Mostly the data in the flap data field will be SNACs, which we will cover next. In hex it can look like this; 5A 5.0 SNACs SNACs are a main part of the OSCAR protocol. There what most of the data sent between the Server and the Client is constructed as. Snacs are only sent on Channel 2. The make up of a snac is as follows. The Family, Sub Type, Flags, Snac Request ID. 5.1 The Family Think of the Family as a numerical representation of a group. For instance, IM's (also known as ICBMs; Inter client Based Messages) are part of family 4. The family is represented by its numeral, and proceeded by a 0. So it would look like this 0 4 in decimal or 00 04 is hex. 5.1.2 The Sub Type If the family is the numerical representation of a group, the sub type represents a member of the group (or the child). If you want to send an IM, you send it with Family 4 and sub type 2. Represented in decimal like this, 0 4 0 2. Or in Hex as 00 04 00 02. 5.3 The Flags The flags are a two byte string. Mostly they are not used, and appear in decimal as 0 0 and in hex as 00 00. 5.4 The Snac Request ID. The snac request ID is a four byte string. It is mostly un-needed. It keeps track of how many snacs have come in, and how many have come out. For all intents and purposes you can just send (Decimal: 0 0 0 0 or Hex: 00 00 00 00). 6.0 Type Length Values (TLVs) Type Length Values (Further known as TLVs) are just that. The Type is a two byte string, the length is a two byte string, and then the value is an a string that is as long as the Length says it is. In Decimal a normal TLV may look like this. 0 1 0 2 0 0 6.1 Decoding TLVs The main reason we decode from hex to decimal is because of TLVs. Its much easier to work with TLVs when you can immeditly see what there representing. Take this TLV for instance and lets decode it. 0 1 0 2 0 0 The first 2 bytes 0 1 <-- thats the type The second 2 bytes 0 2 <-- thats the length of data that were about to see. 0 0 <---thats the two bytes of data the length was talking about. TLVs can get very complicated, and a TLV can have a TLV inside it like this 0 10 0 2 0 3 0 11 0 0 0 0 0 0 0 0 0 0 0 0 10 <-- Type 0 2 <-- Len 0 3 0 11 0 0 0 0 0 0 0 0 0 0 0 <--- Value But Inside the value we have another TLV 0 3 <--Type 0 11 <-- Len 0 0 0 0 0 0 0 0 0 0 0 <--- Value This is why decoding is much easier in decimal then hex. Imagine if we had that same TLV, but in hex form. 00 0A 00 02 00 03 0B 00 00 00 00 00 00 00 00 00 00 00 You would need to know that 0A = 10 and that 0B = 11. Thats not that hard, but what if it was A3 instead of 0A. Then you would have to de hex that anyways, to figure out what it meant. So why not just change everything from hex to decimal straight away, and save yourself some time. 6.2 Value Lengths I've noticed something that appears in OSCAR packets, that has to do most of the time with screennames. I call it a Value Length. Its unofficial at most. I've just seen it appear enough to give it its own name. It works looks like this. 0 9 52 52 52 52 52 52 52 52 52 0 9 <-- The Length 52 52 52 52 52 52 52 52 52 <---Value Mostly the 52's would be a screenname. The Value in this case is always an ASCII string, meaning a screenname or some other text. Sometimes, when your setting up a chat, its used. I just thought I would put it in, because its not an actual TLV and it had me confused for awhile. 7.0 The Servers Oscar has a single login approach to things. Since there are multiple services that AIM has to offer, they needed a way to have the user login only once. 7.1 The Authorization Server Everything starts with the Auth server. When you want to connect to AIM, your first connection is sent to the Auth server. When you connect AIM sends a challenge string, that you have to encode, along with the password, and ********** in MD5 encryption and send to the server. It does the same ting, and compares the string. After you connect and go through the Authorization process it gives you a cookie (Not food). This cookie is used as your password to get into any of the other AIM servers that you may want to use. 7.2 The BOS Server BOS stands for Basic OSCAR Services. This is the server that IMs and buddy list info are sent on. Almost all Oscar features can be accessed from this server. After were done with the Auth server, we connect to the BOS server and send our cookie. Then we finish the login sequence, by requesting our rights, our buddy list, our rate limit, warning level, etc. And also by setting our info, and privacy features. 7.3 Server Redirections Server redirections are a standard OSCAR happening. You don't so much leave one server for another, as you set up another connection. If you want to do something aside from send IMs and use your buddy list normally, chances are you need to start a connection to another server. This is all part of the single login technique used with OSCAR. We request whatever server we want to start a connection too, and it sends us the servers IP. We connect to it and send our cookie. The process for connecting to a new server, is almost exactly the same as connecting to the BOS server. The different servers are as follows. 7.3.1 The Chat Rights Server To gain access to the chat server, we send a packet to the BOS server that requests a chat server. The BOS server responds with a Chat Server, and we connect to it, and send our cookie. Then we go through the process of setting up our rate limit etc with that. After all that is done, we send the request to create a chatroom, if the request is accepted, then we are allowed to create the chatroom. This request should be sent to the BOS server, and not the Chat Server. We will then receive yet another Chat Server from the BOS, and we will connect to that as well. 7.3.2 The Chatroom Server This server, after receiving it from the BOS server goes through the same login process as the previous chat server. This is the server that sends us messages from the room, and allows us to send messages to the room. (If we disconnect from this server we will be shown to leave the room. If we set up the chatroom, and send the join command, and don't connect to the chatroom server we are still shown to join the room, and then leave it a few seconds or minutes later, this is known as Ghost Leave) 7.3.3 The E-Mail Server This server is used to update the email address. E-mail updating works like this... You send the update email packet, and AIM sends a notification to your current email address making sure it was you that sent the update email request. If you respond to the email the request is canceled, if you don't, after 72 hours it goes through and the email is updated. 7.3.4 The Password Server The password server is still used to update or change your password, even though the newer AIMs now use a web based password change form. You send your current password, and then what you want your password to be, and it changes it for you. 7.3.5 The Format Server This server allows you to format your name with spaces etc. You send what you want your name to look like, and it either goes through, and you get an Update Buddy packet showing your new name, or it doesn't work and you get an error back. 7.3.6 The AD server This server is what sends the advertisement addresses for the images that appear in your AIM. I have not really explored this server much because I don't like ads. 8.0 Capabilities Capabilites (AKA Caps) are sent along with the profile during login to the BOS server. A full cap string looks like this The great thing about Oscar, is that caps can be added by anyone. All it takes for a cap to be useful it two people using it. If you make your own client you can create your own cap. Trillian does it I belive with an encryption cap. AIM Pimped is going to have a Web cam cap. Caps work like this. You send an IM, and inside that IM is a cap string going along with the message. The Client can interpret this anyway it wants. If it knows what the Cap is, it will present the request to you. (Like a Direct Connect, or File Transfer) If it doesn't know what the cap is, it sends back something saying it does not support that capability. You can make a custom cap, by making your own cap string and sending it during login. A custom cap would look like this Notice its almost exactly like all the other caps, and if you look at your capabilities in normal AIM (by hovering over the name your signed on as) you will see some gibberish there, that is AIM not knowing what to put for that capability string. If you make a client that recognizes that cap, then you and they, if both running the same client, could use that cap. Existing capabilites are as follows. 8.1.1 Direct Connect (IM Image) This cap allows you to connect directly to your buddy, and it also shows you there IP, and them, yours. You can send images this way, and talk without a rate limit. In AIM 5.2 they redesigned the DC, to make it go through a server that acts as a proxy, thus not allowing you to get there IP. This also defeats the purpose of a DC because it can now be monitored by AIM if they saw a reason too. The previous method of DC is still possible. It is still possible to Connect to someone directly. I do it on AIM 5.9. 8.1.2 File Transfer File transfer can also reveal your IP. It sends the file as ASCII, basically just reading the file your trying to send, and sending the packets. 8.1.3 Send Buddy list This cap allows you to send a buddy list to someone. 8.1.4 Get Buddy list This cap allows you to receive a buddy list from someone. 8.1.5 Talk This cap has not been completely figured out, even by the creators of GAIM. It is currently the only capability that cannot be used except by a normal AIM Client. 8.1.6 Security This new cap (as of Windows 5.2) allows you too import digital certificates that can encrypt your IMs. The lock that appears next to a users name that is using a digital certificate is just like an away message. It does not actually mean the user is using a digital cert. Its just for looks. If you send the security cap during login it puts the lock next to your name. 8.1.7 Buddy Icon Buddy Icons I have not fully explored. They need to be no bigger then 7k. They are sent along with an IM. 8.1.8 Chat The ability to send and receive chat invites, and join chartrooms. 8.1.9 IM The ability to receive and send IMs. 9.0 Server Stored Information (SSI) For along time now, since around Windows AIM 2.5 the users buddy list has been stored on the AIM server. As it has evolved, more and more information has been stored on the AIM server. All of the info that is stored remotely, and can be accessed by the client is SSI. 9.1 Buddy lists The buddy list is one of the most complex parts of OSCAR. If your just starting out, I don't recommend trying to tackle the buddy list until you are very familiar with OSCAR, and decoding packets. Although I will try to explain it fully here another good reference for the Buddy list is king-ant.net. The buddy list belongs to family 13, this is the SSI family. Almost data that is stored remotely about the client, takes place in family 13. The problem with the buddy list, is that if it is big, (consisting of many screennames and or groups) it is sent in more then more packet. The maximum size of a packet has a length of 1414. So if the buddy list is larger then that, it overflows to the next packet, and you have to put it back together yourself. This shouldn't be too hard, because once you receive the first packet, you should know that the rest are probably coming. They will not have FLAP or SNAC headers, it will just continue from where it left off (at the same point as you would normally see a character 42 (asterix)) Once you have the fully compiled buddy list, you need to parse it. This is probably the hardest thing you can do. If your making your own client, parsing the buddy list is not only the hardest thing you will have to do (aside from file transfer and possibly direct connect) but its the most important. When you parse the buddy list, you get more then just the groups and screennames. You get the Group ID, Buddy ID, and Buddy Comments. 9.1.2 Group ID In order to know where to put the screennames you parse, you have to look at the group id. Every group on your buddy list has an ID. When you parse the buddy list for a screenname, you get the group ID, and you can put the buddy in the group with that ID. If its a group that your parsing the group ID will be that of the group. The buddy id for a group id 0 0 in decimal and 00 00 in hex. As you may have figured out the Group ID is a two byte string. 9.1.3 Buddy ID The buddy ID is also very important. Every screenname has a unique buddy id. If a screenname appears on your buddy list twice, for each time it appears it will have a unique buddy id. This is crucial because if you want to remove a Buddy from your buddy list, not only to you have to send the name of the buddy, but also the unique buddy id. (Because names can appear on your list more then once in different groups) Many Buddy list features require you to send the Buddy ID and group ID as well. As you may have figured out, the Buddy ID, like the group ID is a two byte string 9.1.4 Comments After you get the Screenname, Group ID, Buddy ID, etc. You have some additional information left over. This info can either be 0 0 in decimal/00 00 in hex, or it can contain some additional information such as the Comments you have saved for this buddy. 9.2 Adding a group to the buddy list If you want to save a new group to the buddy list, you send the server the add group packet, and the name of the group, and a unique group id. 9.3 Removing a group from the buddy list If you want to remove a group (and all of its contents) from the buddy list you send the remove group packet, the name of the group, and then the group id 9.4 Renaming a group on the buddy list To rename a group on the buddy list you simply send the name of the group, the name you wish you change it too, and then the group id. The group ID does NOT change, although the name of the group does. 9.5 Renaming a buddy Renaming a buddy can be done using the same Family and Sub type as renaming a group, and it follows the same protocol, name of the buddy, name to change it too, and the buddy id. Again the buddyid does not change. Although this method works, Windows AIM does not so much rename a buddy, as delete it, and then add the new name. It is more efficient to rename it though. 9.6 Adding a Buddy to the buddy list You send the add buddy packet, which includes the name of the buddy, the group id, and then a unique buddy id. This can be made up, as long as its not the same as any other buddyid or group id. 9.7 Removing a buddy from the Buddy list If you want to remove a buddy from the buddy list, you send the remove buddy packet, and include the name of the buddy, its group id, and its unique buddy id. 10. Member Info Member info is available in two forms. The first being the profile the user sends when they sign on. The second being the Directory into that they set either the first time they sign on, or when they update there profile. Both are easy to parse. 10.1 Getting the Profile The profile can yield some good info about the user. When you request someone's profile, you not only receive the profile, but how long they have been online, there warning level, if there away, and how long they have been away/idle. 10.2 Getting the Directory Info The directory info is setup when the user signs on for the very first time, and can be updated along with the profile. It can give you things like the users first, and last name, address, zip code, and nick name. It is only available if the user sets it up. 11. (The rest hasn't been written yet.)